home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SPACE 2
/
SPACE - Library 2 - Volume 1.iso
/
program
/
561
/
prolog
/
anhang.doc
(
.txt
)
< prev
next >
Wrap
ST Writer Document
|
1991-09-08
|
17KB
|
423 lines
Do Run Run STWRITER.PRG
Anhang
zur Dokumentation von TOY Prolog ST, Version 3
Inhalt
A.1 Aufbau des Interpreters
A.2 Syntax des inneren Interpreters
A.3 Die Systemdatei
A.4 Die Implementierung der Benutzerschnittstelle
A.5 Erweiterungen in der vorliegenden Version von TOY Prolog ST
in Bezug auf die Dokumentation.
A.1 Der Aufbau des Interpreters
TOY Prolog besteht aus zwei Teilen, dem inneren und dem
eren
Interpreter. Der innere Interpreter ist in C und 68000-Assembler
geschrieben, der
ere bereits in Prolog selbst. Der Vorteil an
einer derartigen Implementierung ist, da
viele Teile des
Interpreters in Prolog erheblich leichter zu formulieren sind als
in anderen Programmiersprachen.
Ein Beispiel daf
r ist das Pr
dikat 'repeat'. In Prolog ist es wie
folgt definiert :
repeat.
repeat :- repeat.
Eine Implementierung von 'repeat' in C w
rde erfordern, die
Datenstrukturen, die der innere Interpreter verwendet, zu
erweitern; der entstehende Mehraufwand w
re betr
chtlich.
Die verwendete Technik hat nat
rlich auch Nachteile. Der gr
davon ist zweifelsohne der der geringeren Geschwindigkeit. Der
gesamte Parser von TOY Prolog ist im
eren Interpreter
implementiert, und aufgrund der komplexen Syntax (TOY Prolog soll
weitgehend mit Prolog-10 kompatibel sein) ist der Parser sehr
aufwendig. Man merkt das besonders schmerzlich beim Einlesen von
Dateien mit 'consult' etc.
Die geringe Geschwindigkeit beim Einlesen von Programmen kann man
auf eine einfache Weise umgehen. Sobald man ein korrektes Programm
vorliegen hat, kann man es in die Syntax des inneren Interpreters
bersetzen. Die Geschwindigkeit, mit der derartige Zwischencodes
eingelesen werden,
bertrifft bei weitem die Lesegeschwindigkeit
eren Interpreters.
Der
ere Interpreter besteht im wesentlichen aus einer
Programmschleife (loop / 0), die Terme mit 'read' einliest und sie
auswertet. Diese Schleife kann auch aus Benutzerprogrammen mit
tag(loop)
aufgerufen werden; sie wird durch das Pr
dikat 'stop' abgebrochen.
Diese M
glichkeit wird z.B. im Editor verwendet.
Die Art und Weise der Implementierung verlangt, da
der
Interpreter nach dem Programmstart eingelesen wird. Deshalb gibt
es in TOY Prolog eine Systemdatei namens 'SYSFILE.TOY'. Sie
lt au
er dem Zwischencode des
eren Interpreters noch
andere wichtige Daten, insbesondere die Namen und Stelligkeiten
der Systemfunktionen und die Definitionen der vordefinierten
dikate. Der Aufbau der Systemdatei wird in Abschnitt A.3
utert.
A.2 Die Syntax des inneren Interpreters
Die Syntaxbeschreibung erfolgt analog zur Beschreibung der vollen
Syntax in Abschnitt II.
Klausel ::= Regel | Ziel
Regel ::= F_Term : Aufrufliste
Ziel ::= : Aufrufliste #
Aufrufliste ::= { Aufruf . } []
Aufruf ::= F_Term
F_Term ::= Funktor | Funktor ( Argumente )
Funktor ::= Name | Q_Name | [] | !
Argumente ::= Term { , Term }
Term ::= ( Term ) | Variable | Zahl | F_Term |
Term . Term
Variable ::= Anonyme_Variable | Numerierte_Variable
Anonyme_Variable ::= _
Numerierte_Variable ::= : Zahl
Zahl ::= Vorzeichen Ziffer { Ziffer }
Name ::= Kleinbuchstabe { Alphanumerisch }
Q_Name ::= ' Q_Zeichen { Q_Zeichen } '
Q_Zeichen ::= '' | Nicht_'
*** Nicht_' ist jedes Zeichen au
Alphanumerisch ::= Kleinbuchstabe | Gro
buchstabe |
Ziffer | _
Vorzeichen ::= + | | -
*** Das Vorzeichen kann auch fehlen.
*** Kleinbuchstabe, Gro
buchstabe, Ziffer siehe Abschnitt II.
uterungen
(1) Der innere Interpreter liest nur Regeln und Ziele ein, wobei
ein Ziel syntaktisch eine Regel ohne Kopf ist. Fakten m
ssen
als Regeln repr
sentiert werden, bei denen die Aufrufliste
gleich [] ist. Ein Ziel wird durch das Zeichen '#' beendet,
das dem Interpreter mitteilt, da
er mit der Auswertung des
Ziels (d.h. mit dem Versuch, das Ziel zu erf
llen) beginnen
soll. Es wird keine Meldung
ber Gelingen oder Fehlschlagen
des Ziels ausgegeben.
(2) Soll der innere Interpreter vom Datenstrom 'user' lesen, so
verh
lt er sich, als habe er das Ziel
: ear . [] #
eingelesen. Dieses Ziel ist der Aufruf des
eren
Interpreters und mu
daher als Pr
dikat vorhanden sein; f
den Fall, da
ein anderes Pr
dikat als 'ear' in der
Systemdatei (siehe Abschnitt A.3) eingetragen wurde, gilt
sinngem
dasselbe.
(3) Anonyme Variablen, die der innere Interpreter einliest,
verhalten sich anders als anonyme Variablen, die vom
eren
Interpreter eingelesen werden. Der innere Interpreter erzeugt
'echte' anonyme Variablen, die nicht mit Werten instantiiert
werden k
nnen. Der
ere Interpreter erzeugt statt dessen
einmalige Instanzen von 'normalen' Variablen. Der Unterschied
ist normalerweise bedeutungslos; man sollte sich aber nicht
darauf verlassen, da
z.B. 'numbervars' wirklich alle
Variablen instantiiert.
(4) Beim Einlesen von 'numerierten' Variablen erzeugt der innere
Interpreter eine Tabelle, anhand derer er erkennt, wieviele
verschiedene Variablen ein Term enth
lt. Der Term
f( :1, :100)
erfordert also nicht 100, sondern nur 2 Variablen. Die einer
Variablen bei der Eingabe zugeordnete Nummer hat nichts mit
der von 'display' oder 'write' ausgegebenen Variablennummer
zu tun; 'display' benutzt die interne Repr
sentation von
Variablen, 'write' deren Reihenfolge im Term.
A.3 Die Systemdatei
Die Systemdatei 'SYSFILE.TOY' besteht aus drei Teilen :
- den Namen und Stelligkeiten bestimmter Funktoren, die vom
inneren Interpreter f
r besondere Aufgaben ben
tigt werden.
Es sind ';' und ',' (ben
tigt f
r die Implementierung des
'cut'), 'tag' und 'call', '[]' und '.', 'error' (f
r die
Behandlung von Aufruffehlern), 'user' (f
r die Ein-/Ausgabe),
die Operatortypen und 'ear' (das Ziel, das vom inneren
Interpreter aufgerufen wird).
Die Beschreibungen dieser Funktoren sollten nicht ver
ndert
werden; ausgenommen davon ist 'ear', das ge
ndert werden
kann, um ein anderes Ziel vom inneren Interpreter aus
aufrufen zu lassen.
- den Namen und Stelligkeiten der Systemfunktionen. Die Namen
der Systemfunktionen k
nnen beliebig ge
ndert werden, aber
die Stelligkeiten m
ssen erhalten bleiben. Wird der Name
einer Systemfunktion ge
ndert, so mu
die
nderung in allen
Programmen, insbesondere im
eren Interpreter, durchgef
werden; andernfalls sind Programme, die die betreffende
Funktion benutzen, nicht mehr lauff
hig !
- der Systembibliothek. Diese enth
lt (in der Syntax des
inneren Interpreters) die Definitionen der vordefinierten
Pr
dikate und den Zwischencode des
eren Interpreters. Auch
hier gilt f
r Namens
nderungen das oben gesagte;
nderungen
der Definitionen haben nicht so weitreichende Folgen, aber
sie k
nnen durchaus dazu f
hren, da
Programme
(einschlie
lich der Hilfsprogramme) nicht mehr lauff
sind. Zu Ver
nderungen an der Benutzerschnittstelle wird im
Abschnitt A.4 noch n
heres gesagt.
Die Beschreibungen der Spezialfunktoren und Systemfunktionen
werden zur Initialisierung des inneren Interpreters verwendet; sie
werden eingelesen, nachdem AES, VDI und die Speicherbereiche des
Interpreters initialisiert wurden.
Die Systembibliothek wird direkt nach der Initialisierung des
inneren Interpreters eingelesen; am Dateiende steht ein 'seen', so
nach dem Einlesen der
ere Interpreter gestartet wird.
A.4 Die Implementierung der Benutzerschnittstelle
Die Syntax des inneren Interpreters ist zwar sehr einfach, daf
sind Programme in dieser Form nur schwer verst
ndlich; ein
Programm von der Gr
enordnung des
eren Interpreters kann daher
nicht direkt im Zwischencode entwickelt werden.
Aus diesem Grund wurde die Benutzerschnittstelle in einer
Untermenge der zu implementierenden Sprache geschrieben. Diese
"Halbsprache" ist in folgenden Punkten gegen
ber der vollst
ndigen
Syntax eingeschr
- Operatornotation und die Verwendung von grammatischen Regeln
ist nicht erlaubt.
- Die Listennotation ist leicht eingeschr
nkt : In einem Term
der Form
[ A, B, C ... | X ]
mu
X eine Variable sein.
- Das Komma in einer Regel und das Symbol ':-' werden als
Trennzeichen (nicht als Operatoren) behandelt. ';' darf in
einer Regel nicht als Trennzeichen, wohl aber als Funktor
verwendet werden.
Das Hilfsprogramm 'BOOTER.TOY' kann diese Notation praktisch 1 : 1
in den Zwischencode
bersetzen.
Der Quellcode der Benutzerschnittstelle befindet sich in der Datei
'MONITOR.PRO'; nach der
bersetzung sollte man aus dem
entstandenen Zwischencode alle Kommentare entfernen, da diese
ziemlich viel Platz verbrauchen. Dabei ist zu beachten, da
manche
dikate, die Kommentare erkennen oder erzeugen (in der
vorliegenden Version sind es 'skip', 'absorbtoken' und
'nextline'), das Zeichen '%' benutzen; man darf also nicht einfach
alle Zeilen l
schen, in denen '%' vorkommt.
ber die Verfahren, die beim Entwurf des
eren Interpreters
angewandt wurden, und
ber dessen Aufbau, kann hier nichts gesagt
werden; eine ausf
hrliche Beschreibung findet sich in "Prolog for
Programmers".
A.5 Unterschiede zur Dokumentation
In der vorliegenden Version 3.3 gibt es folgende Unterschiede zu
dieser Dokumentation:
- Die Bet
tigung der Tasten 'Control' 'C' f
hrt in vielen
F
llen zum sofortigen Abbruch des
eren Interpreters. Das
Programm verh
lt sich so, als ob nach einer Unterbrechung mit
'Shift' 'Alternate' 'Help' die Option A (Abbruch) gew
wurde.
Der innere Interpreter wird nicht abgebrochen; wird gerade
keine Datei eingelesen, so wird der
ere Interpreter wieder
gestartet.
- Falls bei einer Diskettenoperation ein kritischer Fehler
(Wechsel der Diskette, falsche Diskette im Laufwerk etc.)
auftritt, erfolgt die Meldung:
There was a critical error. (A)bort, (R)etry or (I)gnore ?
Die Eingabe von 'A' f
hrt zum Abbruch (mit einer
Fehlermeldung); 'R' veranla
t einen neuen Versuch, und bei
'I' wird der Fehler ignoriert (Vorsicht !).
- Die Anzeige der Teilziele im Testmodus ("CALL", "REDO",
"EXIT", "FAIL") funktioniert (noch) nicht richtig. "FAIL"
wird bei jedem Mi
erfolg, auch vor einem 'backtrack',
angezeigt, nicht nur (wie es richtig w
re) nach dem
endg
ltigen Fehlschlag des Teilzieles. Im Gegensatz dazu wird
"EXIT" nicht bei allen erfolgreich erf
llten Zielen
angezeigt.
Es ist zweifelhaft, ob diese Mi
nde noch behoben werden
(k
nnen ?). Der "FAIL"-Fehler ist beim Programmtest
hinderlich und wird wahrscheinlich noch ausgemerzt, aber der
"EXIT"-Fehler ist teilweise durch die optimierte (!)
Ausf
hrung von rekursiven Pr
dikaten bedingt und kann -
zumindest in dieser Situation - nicht verhindert werden.
(TOY Prolog f
hrt eine 'tail recursion optimisation' (TRO)
durch, d.h., da
die 'activation records' von Pr
dikaten
zerst
rt werden k
nnen, falls dadurch Speicher gespart wird.
Der Name kommt von rekursiven Pr
dikaten, bei denen der
rekursive Aufruf der letzte in seiner Klausel ist; allerdings
erstreckt sich die TRO auch auf andere Situationen, wie z.B.
den 'cut')
- Es wurden drei weitere Systemfunktionen implementiert, die
auf die Dateiverzeichnisse des Betriebssystems zugreifen :
disk_dir (VAR)
instantiiert PAR_1 mit dem Namen des aktuellen
Dateiverzeichnisses, d.h. mit der Laufwerksbezeichnung und
dem Pfadnamen.
disk_dir (NAME)
macht das durch PAR_1 angegebene Dateiverzeichnis zum
aktuellen Dateiverzeichnis. Die Laufwerksbezeichnung kann
fehlen; in diesem Fall wird das aktuelle Laufwerk benutzt.
Ist PAR_1 fehlerhaft, so wird ein Systemaufruffehler erzeugt.
disk_search (NAME, INTEGER, TERM, TERM)
PAR_1 und PAR_2 sind Parameter f
r den Betriebssystemaufruf
F_SFIRST : Es wird nach der ersten Datei im aktuellen
Dateiverzeichnis (oder in einem Verzeichnis, das durch einen
in PAR_1 vorhandenen Pfadnamen bestimmt wird) gesucht, die
dem Suchmuster in PAR_1 entspricht, und deren Attribute dem
Suchattribut PAR_2 entsprechen. Das Suchmuster wird wie ein
Dateiname angegeben; allerdings k
nnen hier die 'wild cards'
* und ? benutzt werden. Im Pfadnamen d
rfen keine 'wild
cards' stehen.
Die Suchattribute werden in PAR_2 bitweise angegeben; im
einzelnen bedeutet
0 Normaler Dateizugriff m
glich
1 Datei ist schreibgesch
2 Datei ist 'versteckt'
4 Datei ist 'Systemdatei' (ebenfalls versteckt)
8 keine Datei, sondern der Name der Diskette
16 keine Datei, sondern Dateiverzeichnis
32 Datei wurde beschrieben und geschlossen (???)
Falls keine entsprechende Datei gefunden wurde, schl
gt der
Aufruf fehl; ansonsten wird versucht, PAR_3 mit dem Namen und
PAR_4 mit den Attributen der gefundenen Datei zu unifizieren.
disk_search (TERM, TERM)
sucht nach der n
chsten Datei, deren Name und Attribute zu
den im letzten Aufruf von disk_search/4 angegebenen
Suchmustern passen, und versucht, PAR_3 mit dem Dateinamen
und PAR_4 mit den zugeh
rigen Attributen zu unifizieren.
Falls keine passende Datei mehr gefunden wird, schl
gt der
Aufruf fehl.
- Die Eingabe von der Tastatur (Datenstr
me 'user' und 'keybd')
wurde ver
ndert. Insbesondere werden die Funktionstasten (F1
bis F10 und der Cursorblock) jetzt ausgenutzt.
Es besteht die M
glichkeit, die Funktionstasten mit
Zeichenketten zu belegen, die beim Bet
tigen der
entsprechenden Tasten so interpretiert werden, als ob sie von
der Tastatur aus eingegeben wurden.
Dazu dient die neue Systemfunktion
set_fstring (INTEGER, NAME).
PAR_1 mu
eine Integerzahl aus dem Bereich von 0 bis 27 sein,
die die gew
nschte Funktionstaste ausw
hlt (s.u.). Die
ausgew
hlte Funktionstaste wird mit einer Zeichenkette
belegt, die durch den Namen von PAR_2 gegeben ist (PAR_2 mu
ein Funktor ohne Argumente sein).
Die Funktionstasten sind wie folgt gekennzeichnet:
0 F1 10 Shift/F1 20 Clr/Home
1 F2 11 Shift/F2 21 Cursor hoch
2 F3 12 Shift/F3 22 Cursor links
3 F4 13 Shift/F4 23 Cursor rechts
4 F5 14 Shift/F5 24 Cursor runter
5 F6 15 Shift/F6 25 Insert
6 F7 16 Shift/F7 26 Undo
7 F8 17 Shift/F8 27 Help
8 F9 18 Shift/F9
9 F10 19 Shift/F10
F
r die Zeichenkette gilt noch folgende Besonderheit :
Steht in der Zeichenkette ein '\', so wird das nachfolgende
Zeichen so interpretiert, als ob die entsprechende Taste
zusammen mit 'Control' gedr
ckt worden w
Ausnahme : Ist das folgende Zeichen wieder ein '\', so gilt
es (wie
blich) als ein einzelnes '\'.
Beispiele : \G - 'Bell', \H - 'Backspace', \M - 'Return'.
Geplante
nderungen :
- Fehler im Testmodus, siehe oben.
- Einbindung von Programmen aus anderen Sprachen (C, Pascal,
Assembler).
(Falls ich jemals dazu komme, mir daf
r einen Grund und eine
Vorgehensweise zu
berlegen ...)
Ende des Anhangs zur Dokumentation von TOY Prolog ST, Version 3